1. Field of the Invention
The present invention relates to computer systems, and more particularly, to an improved computer system for operating a distributed system landscape.
2. Discussion of the Related Art
Organizations use enterprise computing systems to manage different business processes through customizable applications that interact with each other. For example, enterprise resource planning (ERP) systems are computer-based systems that manage an organization's assets, financial resources, materials, and personnel. A distributed system landscape, such as an ERP system landscape, may include several different application components that may share data with each other. These application components may include a customer relationship management (CRM) system, an ERP application system, a warehouse management system, and a decision support system.
Existing ERP systems include a central design time repository that is accessible to each application component of the ERP system landscape. Content objects that are used in each application component are initially developed for mandatory inclusion in the central design time repository. Content objects identify fields, structure, and sources of data used in the application. This information may be stored as metadata in the central design time repository. Each time a new application is added to an ERP system landscape, the corresponding content objects used in the application must also be added to the central design time repository. If the content objects of a particular application are not added to the central design time repository, the application may not be able to exchange data with other applications within or outside the ERP system landscape.
The central design time repository requirement in existing ERP system landscapes has several disadvantages. First, because content objects used in applications must be added to the central design time repository, developers writing new applications must also create content object metadata for inclusion in the central design time repository. This is cumbersome and inefficient for developers who may be familiar with certain programming languages used to create their application but not familiar with the structure or programming of the central design time repository, as the developers must invest additional resources in creating the content object metadata. Typically, the developers trying to integrate the various applications into one common ERP system landscape of a particular company are familiar with the programs for operating business workflows of the company, but are not familiar with the operation and maintenance of the central design time repository typically provided by IT-companies.
Additionally, the requirement also creates additional shipment and installation inefficiencies. This is because two separate shipment channels and installations may be needed to incorporate the new application in an ERP system. The first shipment channel may include software and/or hardware containing the new application, which may be installed as a separate system or as part of an existing system. The second shipment channel may include the application specific content object metadata for inclusion in the central design time repository. Aside from installing the application itself on an application system, the content object metadata must also be installed on the separate repository system storing the central content repository. Two shipment channels are typically used because the central design time repository system is structurally distinct from the application systems and also often located in another region.
This existing approach is disadvantageous, as two shipment channels per application are required in order to distribute generated runtime objects as well as a corresponding configuration to a computer system operated by a customer.
In state-of-the-art systems, applications are provided to first processing system(s) of the distributed system landscape via a first shipment channel. The metadata required by each application to communicate data via the central design time repository is transferred to the central design time repository via a second shipment channel. Thus, each customer operating a distributed system landscape comprising a plurality of applications and the central design time repository is required to manage to related data packages being received via two different shipment channels. This is highly inefficient and error-prone. In addition, according to many state-of-the-art systems, a developer developing an application for use within a distributed system landscape is required to use a different development suite for specifying the metadata of an application and for developing or adapting the application. Switching between different development environments is perceived by most developers as highly inconvenient and inefficient, because development environments tend to be highly complex software applications and require a lot of work and time in order to get used to the tools provided by each development environment.
FIG. 1 shows a configuration of an existing distributed system landscape 100 including a plurality of applications 110, 120, 130, 160, 180, herein also referred to as ‘application systems’. This distributed system landscape 100 may be, for example, an ERP system landscape. The ERP system landscape may have originally included a CRM application system 110, an ERP application system 160, and a central design time repository 101 storing content objects 111 and 161 for CRM system 110 and ERP application system 160, respectively. During runtime, the CRM 110 and ERP application 160 systems may communicate with the central design time repository 101 to access the content objects 111 and 161 associated with the respective application system 110 and 160. This communication of the depicted state of the art system is necessary because each of the content objects 111 and 161 identify fields, structure, and sources of data used in the respective application 110 and 160.
Once the ERP system landscape 100 has been deployed, developers may develop new applications or application upgrades or organizations may decide to addition functionality to their ERP system landscape 100. For example, a developer may release a new version 2.0 of a CRM system 120, followed later by an even newer version 3.0 of CRM system 130. Alternatively, an organization may decide to add another application component, such as a decision support system 180, to include additional functionality in its ERP system landscape 100.
However, in each of these situations, in order to fully integrate these new systems 120, 130, and 180 in the existing ERP system landscape 100, the content objects 121, 131, and 181 for each of these respective new systems must also be added to the central design time repository 101. Thus, there is a need for systems and methods where new applications added to an ERP system include self-contained content objects that do not have to be separate structured, formatted, and included in a central design time repository.